Sustainable Cyberinfrastructure Software Through Open Governance

The authors discuss their position on open governance, open source software, and sustainability

Building Problem Solving Environments with Application Web Service Toolkits

Application portals, or Problem Solving Environments (PSEs), provide user environments that simplify access and integrate various distributed computational services for scientists working on particular classes of problems. Specific application portals are typically built on common sets of core services, so reusability of these services is a key problem in PSE development. In this paper we address the reusability problem by presenting a set of core services built using the Web services model and application metadata services that can be used to build science application front ends out of these core services

CTSC Recommended Security Practices for Thrift Clients: Case Study - Evernote

The Science Gateway Platform (SciGaP, scigap.org ) will provide services to help communities create Science Gateways. SciGaP (via Apache Airavata) will use the Apache Thrift framework ( thrift.apache.org ), a language independent, richly typed interface definition language (IDL) to generate both client and server software development kits (SDKs). Thrift takes a departure from many public services in that it is not a RESTful( http://en.wikipedia.org/wiki/Representational_state_transfer ) API. To gain a better understanding of Thrift (for the CTSC-SciGaP engagement), we examine an existing application/service that uses it: Evernote (evernote.com). Hopefully, the design and use cases of Evernote will help inform the design and use cases of SciGaP, at least from a security perspective. This document provides an overview of Evernote with an emphasis on its Cloud API, some examples of its SDKs, and a list of recommended practices for using Evernote.National Science Foundation, Grant Number 1234408

Authentication and Authorization Considerations for a Multi-tenant Service

Distributed cyberinfrastructure requires users (and machines) to perform some sort of authentication and authorization (together simply known as "auth"). In the early days of com- puting, authentication was performed with just a username and password combination, and this is still prevalent today. But during the past several years, we have seen an evolution of approaches and protocols for auth: Kerberos, SSH keys, X.509, OpenID, API keys, OAuth, and more. Not surpris- ingly, there are trade-offs, both technical and social, for each approach. The NSF Science Gateway communities have had to deal with a variety of auth issues. However, most of the early gateways were rather restrictive in their model of access and development. The practice of using community credentials (certificates), a well-intentioned idea to alleviate restrictive access, still posed a barrier to researchers and challenges for security and auditing. And while the web portal-based gate- way clients offered users easy access from a browser, both the interface and the back-end functionality were constrained in the flexibility and extensibility they could provide. Design- ing a well-defined application programming interface (API) to fine-grained, generic gateway services (on secure, hosted cyberinfrastructure), together with an auth approach that has a lower barrier to entry, will hopefully present a more welcoming environment for both users and developers. This paper provides a review and some thoughts on these topics, with a focus on the role of auth between a Science Gateway and a service provider.National Science Foundation, Grant Numbers 1339774 and 1234408

The CSBG - LSU Gateway: Web based hosted gateway for computational system biology application tools from Louisiana state university

© 2018 Copyright held by the owner/author(s). Science gateways are identified as an effective way to publish and distribute software for research communities without the burden of learning HPC (High Performance Computer) systems. In the past, researchers were expected to have in-depth knowledge about using HPC systems for computations along with their respective science field in order to do effective research. Science gateways eliminate the need to learn HPC systems and allows the research communities to focus more on their science and let the gateway handle communicating with HPCs. In this poster we are presenting the science gateway project of CSBG (Computational System Biology Group - www.brylinski.org) of Department of Biological Sciences with Center for Computation & Technology at LSU (Louisiana State University). The gateway project was initiated in order to provide CSBG software tools as a service through a science gateway

SWARM: Scheduling Large-Scale Jobs over the Loosely-Coupled HPC Clusters

Abstract — Compute-intensive scientific applications are heavily reliant on the available quantity of computing resources. The Grid paradigm provides a large scale computing environment for scientific users. However, conventional Grid job submission tools do not provide a high-level job scheduling environment for these users across multiple institutions. For extremely large number of jobs, a more scalable job scheduling framework that can leverage highly distributed clusters and supercomputers is required. In this paper, we propose a high-level job scheduling Web service framework, Swarm. Swarm is developed for scientific applications that must submit massive number of high-throughput jobs or workflows to highly distributed computing clusters. The Swarm service itself is designed to b

A Credential Store for Multi-tenant Science Gateways

Science Gateways bridge multiple computational grids and clouds, acting as overlay cyberinfrastructure. Gateways have three logical tiers: a user interfacing tier, a resource tier and a bridging middleware tier. Different groups may operate these tiers. This introduces three security challenges. First, the gateway middleware must manage multiple types of credentials associated with different resource providers. Second, the separation of the user interface and middleware layers means that security credentials must be securely delegated from the user interface to the middleware. Third, the same middleware may serve multiple gateways, so the middleware must correctly isolate user credentials associated with different gateways. We examine each of these three scenarios, concentrating on the requirements and implementation of the middleware layer. We propose and investigate the use of a Credential Store to solve the three security challenges